A Portal for Software Security

software security—remain blithely unaware of their critical role. Without their direct participation, software security will languish. In this installment of Building Security In, we describe a software security portal that the US Department of Homeland Security (DHS) National Cyber Security Division (NCSD) is developing (along with the Carnegie Mellon Software Engineering Institute [SEI] and Cigi-tal). The launch of this portal is scheduled for October 2005 as part of the US-CERT Web site. The portal aims to provide a common, accessible, well-organized set of information for practitioners wishing to do software security. Since 1999, several seminal books have helped define the software security field. 1–3 These books introduced the approach to building security in, which practitioners have since enhanced, expanded, and published in various technical articles, including the Building Security In series (see the sidebar). The core philosophy underlying this approach is that security, like dependability and reliability, can't be added onto a system after the fact through the addition of sets of features , nor can it be tested into a system. Instead, security must be designed and built into a system from the ground up. More than 90 percent of reported security incidents are the result of exploits against defects in the design or code of software, according to the CERT Coordination Center (CERT/CC) of the SEI. Although traditional security efforts attempt to retroactively bolt on devices that make it more difficult for those defects to be exploited, such devices simply aren't effective. Standard-issue software development lifecycle models—ranging from the process-heavy Capabilities Maturity Model (CMM) to the lightweight Extreme Programming (XP) approach—are not focused on creating secure systems. They all exhibit serious shortcomings when the goal is to develop systems with a high degree of assurance. 4 If they even address security issues at all, they're most often relegated to a separate thread of project activity fo-cused on security features; as a result, security is treated as an add-on property. For example, although using applied cryptography (such as SSL) to protect message traffic is a useful security feature, the union of all such security features doesn't ensure secure software. Any isolation of security considerations from primary system-development tasks results in an unfortunate and untenable separation of concerns. Security should be integrated and treated on a par with other system properties. The only way to develop systems with required functionality and performance that can also withstand malicious attacks is to …